Machine-type communication (MTC) applications often send or receive small quantities of data, which can be referred to generally as small data. In some cases, if “small data” applications engage in communication sessions that are infrequent, resources within a communication network, for instance a 3GPP system, are used inefficiently.
If an MTC application on a given user equipment (UE) needs to obtain services from a 3GPP network, it must first “attach” to the network. An attach procedure may be performed by a UE after it is powered on. FIG. 1A depicts an example attach procedure that is performed in a 3GPP network 200. At a high level, the attach procedure informs the network about the presence of the UE, and the attach procedure establishes a default bearer within the network to allow traffic to flow to or from the UE. Referring to FIG. 1A, in accordance with the illustrated example, at 201, a UE 202 issues an Attach Request that includes various parameters such as: the identity of the UE 202; the type of connection requested (e.g., Packet Data Network (PDN) Type); and optionally an Access Point Name (APN), which is a character string that refers to the packet data network to which the UE 202 is requesting access. At 203, this information is forwarded from a 3GPP base station 204 to a Mobility Management Entity (MME) 206. The MME 206 uses the APN information to select the packet data network with which to make a connection, and then uses the PDN Type to determine the type of connection (e.g., IPv4 and/or IPv6). The MME 206 may verify that the UE 202 has access to the PDN by querying (at 205a) the device's subscription profile contained in a Home Subscriber Server (HSS) 208. If the UE 202 does not provide an APN, for example, the MME 206 may use a default APN that is defined as part of the UE's subscription profile. The exchange between the MME and HSS (at 205a and 205b) may be an Update Location Request/Answer or Insert Subscriber Data Request/Answer exchange. Either way, the MME 206 may determine the PDS and the PDN gateway (PDN-GW). As shown, at 207, the MME may then setup the bearers in the 3GPP network 200. At 209, the MME 206 may issue an Attach Accept message to the UE 202 via the base station 204. At 211, the UE 202 may then terminate the attach procedure with an Attach Complete message, which may be sent to the MME 206 via the base station 204.
After attachment, for instance after the attachment procedure shown in FIG. 1A is performed, when applications on a given user equipment (UE) are not communicating, the radio bearers are released and the UE may move to an IDLE state. As used herein, unless otherwise specified, a UE that is in an IDLE state or mode refers to a UE that is in an evolved packet core (EPC) mobility management (EMM)-REGISTERED state and an evolved packet system (EPS) connection management (ECM)-IDLE state. By way of further example, if a given application wants to establish a connection with the UE that is idle, then the UE would have to transition to a CONNECTED mode by establishing the data bearers and the signaling connection with the network. As used herein, unless otherwise specified, a UE that is in a CONNECTED mode refers to a UE that is in an ECM-CONNECTED state.
For UEs that send or receive only small amounts of data, the above-described transition may cause inefficiencies, for example, because the relative signaling overhead to perform the small data transfer is large. This resource issue is not restricted to MTC applications, and may be applicable to any application that performs small data communication. To address this issue and to support transmissions of small data with minimal network impact, which may refer to signaling overhead, the use of network resources, and a delay for reallocation for example, solutions have been proposed in 3GPP TR 23.887, “Machine-Type and other Mobile Data Applications Communications Enhancements.” The solutions described in 3GPP TR 23.887 for Small Data and Device Triggering Enhancements (SDDTE) can be broadly categorized into two categories: 1) using the radio access network (RAN) control plane for small data (SD); and 2) using the data plane for SD.
In example methods that use the RAN control plane for small data, the data is transferred over a Signaling Radio Bearer (SRB) between the Evolved Node B (eNB) and the User Equipment (UE) on the air interface. The eNB to Core Network (CN) transfer may use the CN control plane over S1-MME interface to a Mobility Management Entity (MME) or the CN data plane over S1-U interface to a Serving Gateway (S-GW). FIG. 1B shows the LTE bearer architecture. In this example, the small data would be carried on a radio bearer to the eNB.
In example methods that use the data plane for small data, the data is transferred over a Data Radio Bearer (DRB) between the eNB and the UE on the air interface. The eNB to CN transfer is mostly performed over the CN data plane over S1-U interface to S-GW. In some cases, however, additional conditions, such as the use of a stateless gateway or restricting to a single bearer for example, may be applied. Referring to FIG. 1B, in this example as implemented in the LTE bearer architecture, the small data would be carried on an E-RAB to the S-GW or on an EPS bearer to the P-GW.
Generally, it is recognized herein that a given UE that is in an idle mode (EMM-REGISTERED and ECM-IDLE state) would have to transition to a connected mode (ECM-CONNECTED) if the UE needs to perform a signaling procedure (e.g., TAU or Detach) or if the UE has uplink data to transmit. When the UE wants to move to the ECM-CONNECTED state to transmit data, the UE performs a Service Request procedure. The Service Request procedure synchronizes the UE and the CN on the bearer information and also establishes the corresponding data bearers. The established data bearers may then be used by the UE to transmit its data.
The case where the UE transitions from ECM-IDLE to ECM-CONNECTED to transmit data is modified in the above-mentioned solutions as described in 3GPP TR 23.887 for SDDTE. Example solutions described in 3GPP TR 23.887 require a new procedure to be used (e.g., data transfer without the service request procedure) or require modifications to the existing procedure (e.g., modifications to the service request procedure). Often the new/modified procedures are initiated from the UE.
Referring to FIG. 2, a Policy and Charging Control (PCC) architecture is shown. The PCC architecture is defined by 3GPP in TS 23.203 “Policy and charging control architecture.” The PCC architecture is used to enforce policies, policy rules, QoS rules, and charging information. The interfaces shown in FIG. 2 are described in detail in section 5.2 of TS 23.203, but are summarized below for convenience. The interfaces now described below are used to provision the internet protocol (IP) flow and its corresponding rules in the 3GPP network.
With reference to FIG. 2, the AF (third party application server) uses the Rx Interface to transfer application level session information (e.g., IP filter information, bandwidth requirements, sponsor data, etc.) to the policy and charging rules function (PCRF). The PCRF forms the policy and charging control (PCC) rule based on the IP flow information, and provisions the Policy and Charging Enforcement Function (PCEF) with this PCC rule using the Gx interface. The PCRF forms the QoS rule based on the IP flow information, and provisions the Bearer Binding and Event Reporting Function (BBERF) with this QoS rule using the Gxx interface. The Sp/Ud interface allows the PCRF to request subscription information about an IP flow based on a subscriber ID. The PCRF uses the Sp interface to interact with the Subscription Profile Repository (SPR) and uses the Ud interface for the User Data Repository (UDR).
Still referring to FIG. 2, interfaces that are used to transfer charging related information are now discussed. The PCRF uses the Sd interface to signal an ADC decision to the Traffic Detection Function (TDF). The PCRF sends policy counter status information to the OCS using the Sy interface. The Gz interface enables transport of service data flow based offline charging information. The Gyn interface allows online credit control for charging in case of ADC rules based charging in the TDF. The Gzn interface enables transport of offline charging information in case of ADC rule based charging in the TDF.
FIG. 3 shows a 3GPP Architecture for Machine Type Communication (MTC). Machine type communication generally involves communication between different devices and/or applications without human interaction. MTC devices may utilize the services of a Service Capability Server (SCS) to communicate with external MTC applications. The 3GPP system basically provides transport for machine-to-machine (M2M) device communication. In addition, the 3GPP system may provide other value added services for machine type communication. It is recognized herein that different architectural models are possible in a 3GPP system based on the relationship of an MTC service provider (SCS) and the 3GPP network operator. Example Architectural enhancements for MTC are defined in 3GPP TS 23.683, “Architecture enhancements to facilitate communications with packet data networks and applications.” The main architecture diagram from TS 23.683 is shown in FIG. 3. A MTC-IWF (Machine Type Communication-Inter Working Function) is introduced in the 3GPP system to enable the communication of 3GPP networks with one or more service capability servers (SCSs). The MTC-IWF may be a standalone entity or a logical entity of another network element. The MTC-IWF hides the internal CN topology and relays or translates information sent over the diameter based Tsp reference point to invoke specific functionality in the CN. Other architectural models are defined in 3GPP TS 23.708. For example, a Service Capability Exposure Function (SCEF) is introduced in the 3GPP System to enable the communication of 3GPP networks with one or more service capability servers (SCSs). The SCEF may be a standalone entity or a logical entity of another network element. The SCEF hides the internal CN topology, relays or translates information that is received via an API call, and interfaces with various core network nodes to invoke the functionality that is requested by the API call. For example, the SCEF may interface with the MTC-IWF, the HSS, the PCRF, the UDR, MME, etc.
It is recognized herein that 3GPP is exploring new small data delivery techniques for MTC communications. For example, the solutions in TR 23.887 address the issue of more efficiently carrying out Small Data transfers by reducing the signaling overhead. Existing approaches, however, lack capabilities and efficiencies.